﻿<h1>表达式估值顺序规则</h1>

<p>
本文将解释各种情形下<a href="expressions-and-statements.html">表达式</a>的估值顺序。
</p>

<h3>一个表达式将在其所依赖的其它表达式估值之后进行估值</h3>

<div>
这属于常识，没什么好解释的。一个显然的例子是一个表达式将在组成它的子表达式都估值之后才能进行估值。
比如，在一个函数调用<code>f(x, y[n])</code>中，
<ul>
<li>
	<code>f()</code>将在它所依赖的子表达式<code>f</code>、<code>x</code>和<code>y[n]</code>估值之后进行估值；
</li>
<li>
	表达式<code>y[n]</code>将在它所依赖的子表达式<code>n</code>和<code>y</code>估值之后进行估值。
</li>
</ul>

<p>
另外，<a href="packages-and-imports.html#initialization-order">程序资源初始化顺序</a>章节中提供了一个关于包级变量初始化顺序的例子。
</p>

</div>

<a class="anchor" id="package-level-variables"></a>
<h3>包级变量初始化顺序</h3>

<div>
<p>
在运行时刻，当一个包被加载的时候，不依赖于任何其它未初始化包级变量的未初始化包级变量将按照它们在代码中的声明顺序被初始化。
此过程可能需要重复若干次，直到此过程中不再有任何包级变量被初始化。
对于一个成功编译了的Go程序，当所有这样的过程结束之后，所有的包级变量都应该被初始化了。
</p>

<p>
在包级变量初始化过程中，呈现为空标识符的包级变量和其它包级变被同等对待。
</p>

比如，下面这个程序应该打印出<code>yzxw</code>。
<ol>
<li>
	在上述过程运行的第一轮，<code>y</code>和<code>z</code>是仅有的两个不依赖于任何其它未初始化包级变量的未初始化包级变量，所以它们将按照它们的声明顺序被初始化。
</li>
<li>
	在上述过程运行的第二轮，<code>x</code>是仅有的一个不依赖于任何其它未初始化包级变量的未初始化包级变量，所以它将被初始化。
</li>
<li>
	在上述过程运行的第三轮，<code>w</code>是仅有的一个不依赖于任何其它未初始化包级变量的未初始化包级变量，所以它将被初始化。
</li>
</ol>

<pre class="line-numbers"><code class="language-go">package main

var (
	_ = f("w", x)
	x = f("x", z)
	y = f("y")
	z = f("z")
)

func f(s string, deps ...int) int {
	print(s)
	return 0
}

func main() {
	f("\n")
}
</code></pre>

<p>
（注意：标准Go编译器1.13之前的版本并未正确地实现上述规则。如果上面这个程序使用标准Go编译器1.12版本编译的话，它将打印出<code>zxwy</code>。）
</p>

<!--
https://github.com/golang/go/issues/31292
https://github.com/golang/go/commit/451cf3e2cd8950571f436896a3987343f8c2d7f6
-->

<p>
通过一个多值表达式源值来初始化的多个包级变量将被一起初始化。
比如，在包级变量声明<code>var x, y = f()</code>中，变量<code>x</code>和<code>y</code>将被一起初始化。
或者说，在它们的初始化之间不会有其它包级变量被初始化。
</p>

如果一些包级变量之间存在着编译器难以觉察的依赖关系，则这些包级变量的初始化顺序是未定义的，依赖于具体编译器实现。
在下面这个Go白皮书中的例子中，
<ul>
<li>
	变量<code>a</code>肯定在变量<code>b</code>之后初始化；
</li>
<li>
	但是变量<code>x</code>有可能在变量<code>b</code>之前、或者在变量<code>b</code>和变量<code>a</code>之间、或者在变量<code>a</code>之后初始化，取决于具体的编译器实现；
</li>
<li>
	函数<code>sideEffect()</code>有可能在变量<code>x</code>初始化之前或者之后被调用，取决于具体的编译器实现。
</li>
</ul>

<pre class="line-numbers"><code class="language-go">// x是否依赖于a和b，不同的编译器有不同的见解。
var x = I(T{}).ab()
// 假设函数sideEffect和x、a以及b均无关系。
var _ = sideEffect()
var a = b
var b = 42

type I interface    { ab() []int }
type T struct{}
func (T) ab() []int { return []int{a, b} }
</code></pre>

<p>
</p>

</div>

<h3>布尔（逻辑）运算表达式中的操作数子表达式的估值顺序</h3>

<div>
<p>
在一个布尔运算<code>a &amp;&amp; b</code>中，右操作数表达式<code>b</code>只在左操作数表达式<code>a</code>被估值为<code>true</code>的时候才会被估值。
所以，操作数表达式<code>b</code>如果需要被估值的话，它肯定在操作数表达式<code>a</code>之后估值。
</p>

<p>
在一个布尔运算<code>a || b</code>中，右操作数表达式<code>b</code>只在左操作数表达式<code>a</code>被估值为<code>false</code>的时候才会被估值。
所以，操作数表达式<code>b</code>如果需要被估值的话，它肯定在操作数表达式<code>a</code>之后估值。
</p>
</div>

<h3>通常估值顺序（The Usual Order）</h3>

<div>
Go白皮书这样描述<b>通常估值顺序</b>：

<div class="alert alert-success">
...，当估值一个表达式、赋值语句或者函数返回语句中的操作数时，所有的函数调用、方法调用和通道操作将按照它们在代码中的出现顺序进行估值。
</div>

<p>
注意：一个显式类型转换<code>T(v)</code>不属于函数调用。
</p>

举个例子，在表达式<code>[]int{x, fa(), fb(), y}</code>中，假设<code>x</code>和<code>y</code>是两个<code>int</code>类型的变量，<code>fa</code>和<code>fb</code>是两个返回值为<code>int</code>类型的函数，则调用<code>fa()</code>保证在调用<code>fb()</code>之前执行。
但是，下面这两个估值顺序没有在Go白皮书中指定：
<ul>
<li>
	变量<code>x</code>（或者<code>y</code>）和调用<code>fa()</code>（或者<code>fb()</code>）的相对估值顺序；
</li>
<li>
	变量<code>x</code>、变量<code>y</code>、函数值<code>fa</code>和函数值<code>fb</code>的相对估值顺序。
</li>
</ul>

下面是Go白皮书中提到的另一个例子：

<pre class="disable-line-numbers111"><code class="language-go">y[z.f()], ok = g(h(a, b), i()+x[j()], <-c), k()
</code></pre>

在此赋值语句中，
<ul>
<li>
	<code>c</code>是一个通道表达式，它将被估值为一个通道值；
</li>
<li>
	<code>g</code>、<code>h</code>、<code>i</code>、<code>j</code>和<code>k</code>是一些函数表达式，它们将被估值为一些函数值；
</li>
<li>
	<code>f</code>是表达式<code>z</code>值的一个方法。
</li>
</ul>

综合考虑上一节和本节上面已经提到的规则，编译器应该保证下列在运行时刻的估值顺序：
<ul>
<li>
	此赋值中涉及到的函数调用、方法调用和通道操作必须按照这样的顺序执行：<code>z.f()</code>→<code>h()</code>→<code>i()</code>→<code>j()</code>→<code>&lt;-c</code>→<code>g()</code>→<code>k()</code>；
</li>
<li>
	调用<code>h()</code>在表达式<code>h</code>、<code>a</code>和<code>b</code>估值之后调用；
</li>
<li>
	<code>y[]</code>在方法调用<code>z.f()</code>执行之后被估值；
</li>
<li>
	方法调用<code>z.f()</code>在表达式<code>z</code>估值之后执行；
</li>
<li>
	<code>x[]</code>在调用<code>j()</code>执行之后被估值。
</li>
</ul>

然而，下列次序在Go白皮书中未指定，它们依赖于具体编译器实现：
<ul>
<li>
	表达式<code>y</code>、<code>z</code>、<code>g</code>、<code>h</code>、<code>a</code>、<code>b</code>、<code>x</code>、<code>i</code>、<code>j</code>、<code>c</code>和<code>k</code>之间的相对估值顺序；
</li>
<li>
	表达式<code>y[]</code>、<code>x[]</code>和<code>&lt;-c</code>之间的相对估值顺序。
</li>
</ul>

根据上述通常估值顺序规则，我们知道下面声明的变量<code>x</code>、<code>m</code>和<code>n</code>的初始值可能将出现歧义。

<pre class="line-numbers"><code class="language-go">	a := 1
	f := func() int { a++; return a }

	// x可能初始化为[1, 2]或者[2, 2]，
	// 因为a和f()的相对估值顺序未指定。
	x := []int{a, f()}

	// m可能初始化为{2: 1}或者{2: 2}，
	// 因为两个映射元素的赋值顺序未指定。
	m := map[int]int{a: 1, a: 2}

	// n可能初始化为{2: 3}或者{3: 3}，
	// 因为a和f()的相对估值顺序未指定。
	n := map[int]int{a: f()}
</code></pre>

<p>
</p>

</div>

<a class="anchor" id="value-assignment"></a>
<h3>赋值语句中的表达式估值和赋值执行顺序</h3>

<div>

除了上面介绍的规则，Go白皮书对赋值语句中的表达式估值和各个单值赋值执行顺序进行了更多描述（原英文描述不是十分精确，在翻译过程中对之略加改进）：

<div class="alert alert-success">
一条赋值语句的执行分为两个阶段。
首先，做为目标值的元素索引表达式中的容器值表达式和索引值表达式、做为目标值的指针解引用表达式中的指针值表达式、以及此赋值语句中的其它非目标值表达式将按照上述通常估值顺序估值。
然后，各个单值赋值将按照从左到右的顺序执行。
</div>

<p>
以后，我们可以称第一个阶段为估值阶段，称第二个阶段为实施阶段。
</p>

<p>
Go白皮书并没有清楚地说明在第二个阶段中发生的赋值操作是否会对在第一个阶段结尾确定下来的各个子表达式的估值结果造成影响，此举曾造成了<a href="https://github.com/golang/go/issues/23188#issuecomment-403951267">一些</a><a href="https://github.com/golang/go/issues/15620">争议</a>。
所以，这里下面将对赋值语句中的表达式估值顺序做出一些补充解释。
</p>

<p>
首先，先明确一下：第二个阶段中发生的赋值操作绝不会对在第一个阶段结尾确定下来的各个子表达式的估值结果造成影响.
</p>

<p>
为了方便下面的解释，对于一个赋值语句，我们假设一个做为目标值的容器（切片或者映射）元素索引表达式中的映射值总是可寻址的。
如果它是不可寻址的，我们可以认为在实施第二个阶段之前，此容器值已经被赋给了一个临时变量（可寻址的）并且在此赋值语句中此容器值已经被此临时变量取代。
</p>

在估值阶段结束之后、实施阶段开始之前的时刻，赋值语句中的每个目标值表达式都已经被估值为它的最基本形式。
不同风格的目标值表达式有着不同的最基本形式：
<ul>
<li>
	如果一个目标值表达式是一个空标识符，则它的最基本形式依旧是一个空标识符；
</li>
<li>
	如果一个目标值表达式是一个容器（数组或者切片或者映射）元素索引表达式<code>c[k]</code>，则它的最基本形式为<code>(*cAddr)[k]</code>，其中一个<code>cAddr</code>为指向<code>c</code>的指针；
</li>
<li>
	对于其它情形的任何一个目标值表达式，它必然是可寻址的，则它的最基本形式为它的地址的解引用形式。
</li>
</ul>

假设<code>a</code>和<code>b</code>为两个可寻址的同类型变量，则下面的赋值语句

<pre class="line-numbers"><code class="language-go">	a, b = b, a
</code></pre>

将按照如下步骤执行：

<pre class="line-numbers"><code class="language-go">// 估值阶段
P0 := &a; P1 := &b
R0 := a; R1 := b

// 最基本形式：*P0, *P1 = R0, R1

// 实施阶段
*P0 = R0
*P1 = R1
</code></pre>

<p>
</p>

下面是另外一个例子，其中<code>x[0]</code>而不是<code>x[1]</code>被修改了。

<pre class="line-numbers must-line-numbers"><code class="language-go">	x := []int{0, 0}
	i := 0
	i, x[i] = 1, 2
	fmt.Println(x) // [2 0]
</code></pre>

上例中的第<i>3</i>行的分解执行步骤如下：

<pre class="line-numbers"><code class="language-go">// 估值阶段
P0 := &i; P1 := &x; T2 := i
R0 := 1; R1 := 2
// 到这里，T2 == 0

// 最基本形式：*P0, (*P1)[T2] = R0, R1

// 实施阶段
*P0 = R0
(*P1)[T2] = R1
</code></pre>

<p>
</p>

下面是一个略为复杂一点的例子。

<pre class="line-numbers must-line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	m := map[string]int{"Go": 0}
	s := []int{1, 1, 1}; olds := s
	n := 2
	p := &n
	s, m["Go"], *p, s[n] = []int{2, 2, 2}, s[1], m["Go"], 5
	fmt.Println(m, s, n) // map[Go:1] [2 2 2] 0
	fmt.Println(olds)    // [1 1 5]
}
</code></pre>

<p>
</p>

上例中的第<i>10</i>行的分解执行步骤如下：

<pre class="line-numbers"><code class="language-go">// 估值阶段
P0 := &s; PM1 := &m; K1 := "Go"; P2 := p; PS3 := &s; T3 := 2
R0 := []int{2, 2, 2}; R1 := s[1]; R2 := m["Go"]; R3 := 5
// 到这里，R1 == 1, R2 == 0

// 最基本形式：*P0, (*PM1)[K1], *P2, (*PS3)[T3] = R0, R1, R2, R3

// 实施阶段
*P0 = R0
(*PM1)[K1] = R1
*P2 = R2
(*PS3)[T3] = R3
</code></pre>

<p>
</p>

下面这个例子将一个切片中的所有元素循环顺移了一位。

<pre class="line-numbers"><code class="language-go">	x := []int{2, 3, 5, 7, 11}
	t := x[0]
	var i int
	for i, x[i] = range x {}
	x[i] = t
	fmt.Println(x) // [3 5 7 11 2]
</code></pre>

<p>
</p>

另一个例子：

<pre class="line-numbers"><code class="language-go">	x := []int{123}
	x, x[0] = nil, 456        // 此句不会发生恐慌
	x, x[0] = []int{123}, 789 // 此句将产生恐慌
</code></pre>

<p>
</p>

<p>
尽管使用复杂的多值赋值语句是合法的，但是在实践中并不推荐使用，因为复杂多值赋值语句的可读性不高，编译速度较慢，并且执行效率相对略低。
</p>

上面已经提到了，并非所有的估值顺序都在Go白皮书中指定清楚了，所以不同的Go编译器对这些未指定的估值顺序有着自己的理解。
一些跨编译器兼容性不好的代码将导致使用不同的编译器编译的程序的运行结果不同。
在下面这个例子中，表达式<code>x+1</code>和<code>f(&amp;x)</code>的估值顺序是编译器相关的，所以此程序输出<code>100 99</code>或者<code>1 99</code>都是合理的。

<pre class="line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	f := func (p *int) int {
		*p = 99
		return *p
	}

	x := 0
	y, z := x+1, f(&x)
	fmt.Println(y, z)
}
</code></pre>

<p>
</p>

下面是另一个可能输出不同结果的程序。它可能输出<code>1 7 2</code>、<code>1 8 2</code>或者<code>1 9 2</code>，取决于不同的编译器实现。

<pre class="line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	x, y := 0, 7
	f := func() int {
		x++
		y++
		return x
	}
	fmt.Println(f(), y, f())
}
</code></pre>

<p>
</p>

</div>

<h3><code>switch-case</code>流程控制代码块中的表达式估值顺序</h3>

<div>
<code>switch-case</code>流程控制代码块中的表达式估值顺序已经<a href="control-flows.html#switch-case">在前面的文章中大致描述过了</a>。
这里仅仅展示一个例子。简单来说，在进入一个分支代码块之前，各个<code>case</code>关键字后跟随的表达式将按照从上到下和从左到右的顺序进行估值，直到某个比较结果为<code>true</code>为止。

<pre class="line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	f := func(n int) int {
		fmt.Printf("f(%v) is called.\n", n)
		return n
	}

	switch x := f(3); x + f(4) {
	default:
	case f(5):
	case f(6), f(7), f(8):
	case f(9), f(10):
	}
}
</code></pre>

<p>
在运行时刻，各个<code>f()</code>调用将按照传给它们参数的大小顺序进行估值，直到和调用<code>f(7)</code>的比较结果为<code>true</code>为止。
所以调用<code>f(8)</code>、<code>f(9)</code>和<code>f(10)</code>将不会被估值。
</p>

输出结果：
<pre class="output"><code>f(3) is called.
f(4) is called.
f(5) is called.
f(6) is called.
f(7) is called.
</code></pre>

<p>
</p>

</div>

<h3><code>select-case</code>流程控制代码块中的表达式估值顺序</h3>

<div>

<p>
当执行一个<code>select-case</code>流程控制代码块时，各个<code>case</code>关键值后跟随的所有通道操作中的通道表达式和所有通道发送操作中的发送值表达式都将被按照它们在代码中的出现次序（从上到下从左到右）估值一次。
</p>

<p>
注意：以通道接收操作做为源值的赋值语句中的目标值表达式只有在此通道接收操作被选中之后才会被估值。
</p>

比如，在下面这个例子中，表达式<code>*fptr("aaa")</code>将永不会得到估值，因为它对应的通道接收操作<code>&lt;-fchan("bbb", nil)</code>是个不可能被选中的阻塞操作。

<pre class="line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	c := make(chan int, 1)
	c <- 0
	fchan := func(info string, c chan int) chan int {
		fmt.Println(info)
		return c
	}
	fptr := func(info string) *int {
		fmt.Println(info)
		return new(int)
	}

	select {
	case *fptr("aaa") = <-fchan("bbb", nil): // blocking
	case *fptr("ccc") = <-fchan("ddd", c):   // non-blocking
	case fchan("eee", nil) <- *fptr("fff"):  // blocking
	case fchan("ggg", nil) <- *fptr("hhh"):  // blocking
	}
}
</code></pre>

上例的输出结果：
<pre class="output"><code>bbb
ddd
eee
fff
ggg
hhh
ccc
</code></pre>

<p>
注意，表达式<code>*fptr("ccc")</code>是上例中最后一个被估值的表达式。
它在对应的数据接收操作<code>&lt;-fchan("ddd", c)</code>被选中之后才会进行估值。
</p>

</div>


